Described below is a method for generating an extended route request message and a method for generating an extended route reply message for a route discovery for a route from a source node of an IEEE 802 connection to a destination node of an IEEE 802 connection including a mesh network path with a source node of the mesh path and a destination node of the mesh path. Also described below is an extended route request message and an extended route reply message. Finally, first and second nodes in the mesh network are described.
The task group IEEE 802.11s (IEEE—Institute of Electrical & Electronics Engineers) defines a standard for WLAN mesh networking (WLAN—Wireless Local Area Network) on OSI layer 2 (OSI—Open Systems Interconnection) right now. A possible network structure for networks with IEEE 802.11s meshes is shown in FIG. 1. All nodes can be within 1 IP hop (IP—Internet Protocol), that is, frames can be sent from any node in any part of the network to any other node in any part of the network solely based on the MAC (MAC—Media Access Control) address of the destination. In contrast to IP, where the IP address also describes the network structure, the MAC address is a real interface ID (ID—identification) without any additional information about network structure. More specifically, the MAC addresses do not give any clue whether the interface with that MAC address is located in the LAN (LAN—Local Area Network), WLAN Mesh or in the “WLAN cell”.
The WLAN mesh network deploys a special routing protocol or path selection protocol inside its part of the overall net-work structure. That means that there has to be a mesh source node and a mesh destination node. With respect to the network architecture depicted in FIG. 1, three nested “connections” can be seen in connection with a WLAN mesh network:                wireless link: the actual wireless link, defined by the transmitter of the radio signal and the receiver of this radio signal        mesh path: the path through the WLAN mesh network from the mesh source node/mesh ingress to the mesh destination node/mesh egress. Mesh source node and mesh destination node are the nodes where a frame enters or leaves the WLAN mesh respectively. The mesh path has one or more wireless links.        802 connection/layer 2 connection: This connection is described by a source MAC address and a destination MAC address from any part of the above network (FIG. 1). Usually, the source MAC address is the MAC address of the interface where the IP packet enters layer 2 and the destination MAC address is the MAC address of the inter-face where the layer 2 frames are handed back to the IP layer. An 802 connection/layer 2 connection may include one or more mesh paths. Or the 802 connection/layer 2 connection might be the same as the mesh path.        
FIG. 1 illustrates this as an example, whereby shortened MAC addresses are used. FIG. 1 shows a wired LAN NET1, a WLAN mesh network NET2 and WLAN-“cell” NET3. The mesh nodes are oval and use the references A-H. A data frame has to be sent from node X1 with MAC address 27:45 in the LAN part to the non-mesh station STA with MAC address e3:33 through the WLAN mesh. This is the 802 connection/layer 2 connection. The mesh path on which the packet traverses the WLAN mesh has the mesh node V with MAC address 21:e5 as mesh source and the mesh node E with MAC address 37:fa as mesh destination. If the mesh node G with MAC address 12:fa has to forward the data frame, the wireless link will be described by the transmitter G with MAC address 12:fa and the receiver D with MAC address 72:54.
Since all 6 MAC addresses can be different as in the paragraph above, a mesh data frame has to support 6 MAC addresses in some cases. The current mesh frame format as defined in Draft amendment to standard IEEE 802.11 ™, ESS Mesh Networking, IEEE P802.11s™/D0.02, June 2006, <grouper.ieee.org/groups/802/11>, has 4 MAC addresses: 2 for the wireless link and 2 for the mesh path or source and destination. A scheme for the use of 6 MAC addresses is known from Chu et. al., “Extension to 6-Address Scheme for TGs Mesh”, 26 Jun. 2006, document number IEEE 802.11-06/841r1, whereby there are MAC addresses 1 and 2 for the wireless link, MAC addresses 3 and 4 for the mesh path, and MAC addresses 5 and 6 for the 802 connection. MAC addresses 5 and 6 can be omitted if mesh path and 802 connection coincide. Additional reference signs of FIG. 1 represent the following functions:    “11” (non-IEEE 802.11) wired LAN, e.g. Ethernet with spanning tree algorithm;    “12” WLAN mesh ad hoc routing;    “13” WLAN “cell” with communication between MAP and STA (standard wireless IEEE 802.11 communication);    “14” A DHCP-server (DHCP—Dynamic Host Configuration Protocol) may be located in NET1;    “15” An IP-router (IP-Internet Protocol) may be located in NET1 for routing IP-based packets to other IP-based networks;    “16” IP subnet.
The current draft of the IEEE 802.11s is not very specific on establishing the mapping between mesh path and 802 connection in HWMP. Moreover, it seems that this problem has not been considered extensively. The general idea seems to be, that the mesh ingress/mesh egress generates and manages routing messages on behalf of the non-mesh nodes. This means, that the non-mesh nodes virtually become mesh nodes, but that the processing of the routing messages is done by real mesh nodes on behalf of the non-mesh nodes. The MAC addresses of the non-mesh nodes will be known inside the mesh and are rout-able. This concept is described for the connection of WLAN stations (STAs in FIG. 1) in section 11A.4.3.1.4.2 (page 78) of the June 2006 Draft amendment to standard IEEE 802.11™. It can be easily extended to mesh portals that are connected to wired LANs.
Gossain et. al., “Packet forwarding for non-routable devices in Multi-hop Wireless Mesh”, 15 May 2006, document number IEEE 802.11-06/0661r0 proposes a route request (RREQ) and route reply (RREP) message scheme for supporting mesh nodes, e.g. station G in FIG. 1, and non-mesh stations or non-routable devices, called STA (STA=stations) on page 6 in the June 2006 Draft amendment to standard IEEE 802.11™. These stations are managed by particular mesh nodes that support an access point (AP). In Gossain et. al., “Packet forwarding for non-routable devices in Multi-hop Wireless Mesh”, 15 May 2006, document number IEEE 802.11-06/0661r0, the MAC-address of an originating device is included to the RREQ-message, whereby this MAC-address shall be either the address of an routable device, such as a mesh node, in case the traffic was generated by itself or an address of a non-routable device in the case the traffic was generated by a non-routable device, which is an STA, currently proxied by itself. An MAC-address of a terminating device is added to the RREP-message, whereby this MAC-address shall be either the address of a routable device in case the traffic was destined to itself or an address of non-routable device, such as a STA, in case the traffic was destined for a non-routable device currently proxied by itself.
However none of the current proposals completely supports a set of mechanisms for establishing the mapping between the mesh path and the 802 connection in the mesh ingress and mesh egress nodes. Especially, there is no mechanism defined for the reactive route discovery as used in AODV (see Chu et. al., “Extension to 6-Address Scheme for TGs Mesh”, 26 Jun. 2006, document number IEEE 802.11-06/841r1) and HWMP. The latter is the default routing protocol of IEEE 802.11s (see the June 2006 Draft amendment to standard IEEE 802.11™).